CAESAR Hardware API

In this paper, we define the CAESAR hardware Application Programming Interface (API) for authenticated ciphers. In particular, our API is intended to meet the requirements of all algorithms submitted to the CAESAR competition. The major parts of our specification include: minimum compliance criteria, interface, communication protocol, and timing characteristics supported by the core. All of them have been defined with the goals of guaranteeing (a) compatibility among implementations of the same algorithm by different designers, and (b) fair benchmarking of authenticated ciphers in hardware. 1 Minimum Compliance Criteria The recommended minimum compliance criteria are listed below: 1.1 Encryption/Decryption Authenticated encryption and decryption should be implemented within one core, but only one of these two operations can be executed at a time (half-duplex). This feature demonstrates an algorithm’s ability to use shared resources for encryption and decryption. Alternatives (not recommended): a) separate cores for encryption and decryption (simplex) b) authenticated encryption and decryption within one core, with both operations capable of running in parallel (full-duplex). 1.2 Variants Only a variant indicated in the cipher specification as the primary recommendation has to be implemented. Other variants, if implemented, should be selectable by changing the default values of generics or constants before synthesis. The implementation of these variants should not affect any benchmarking results for the main variant. 1.3 Key scheduling Key scheduling should be fully implemented within the hardware core. This approach takes into account very different contributions of the key scheduling unit to the entire cipher core area, which are specific for each algorithm. An alternative (not recommended): a) generation of round keys outside of the cipher core, e.g., in software. 1.4 Incomplete blocks The core should properly handle incomplete blocks in associated data, message, and ciphertext. Handling of incomplete blocks substantially increases the core area for multiple candidates, due to the large area required for variable shifts. An alternative (not recommended): a) handling only associated data, messages, and ciphertexts composed of full blocks. 1.5 Padding Padding in hardware, assuming that an unused portion of the last input data word is filled with zeros. Padding cost, in terms of area, is algorithm dependent, and not negligible. In some algorithms, padding in software may need to be reversed in hardware because the tag calculation uses an unpadded last block. Alternatives (not recommended): a) Padding in hardware, assuming that an unused portion of the last block is filled with zeros. b) Padding in software, followed, if needed, by modifications of the last blocks in hardware. 1.6 Unused portions of the last block Clearing any unused portions of the last word during encryption and decryption. An alternative (not recommended): a) potentially leaking some key-related data using unused portions of the last block. 2 1.7 Decrypted message release Releasing the decrypted message blocks immediately. We assume that the delayed release of decrypted data, dependent on the result of authentication, will be handled by an external circuit, which is FIFO-based and similar for each candidate. An alternative (not recommended): a) storing a decrypted message internally, until the result of verification is known. Pros: More complete functionality. Cons: Complicates the design and benchmarking. Makes the calculation of the output latency and throughput dependent on the output buffer size and implementation details (e.g., support for simultaneous reading and writing). 1.8 Empty AD/message/ciphertext Allowing empty associated data, empty message/ciphertext, and and empty input (no AD, no message/ciphertext) Empty input could be used together with the input message number, Npub, for user authentication. Alternatives (not recommended): a) not allowing empty associated data b) not allowing empty message/ciphertext c) not allowing empty input. 1.9 Supported maximum size of AD/plaintext/ciphertext single-pass authenticated ciphers: 232 bytes two-pass authenticated ciphers: 211 bytes Maximum sizes defined in the CAESAR candidates’ specifications are unrealistic. Too large values may affect both area and maximum clock frequency of the hardware core (e.g., because of wide internal counters). 211 bytes > 1500 bytes = maximum transmission unit (MTU) of popular communication protocols, such as Ethernet v2.